Unified routing scheme for ad-hoc Internetworking

ABSTRACT

The Invention provides methods and apparatus for determining various cost metrics for routing in a computer network. The cost metrics may include measures of interference over time to neighbor nodes of a first node of the computer network per data bit transmitted on a communication link used by the first node. Such a metric may be estimated using the RF transmit power used by the first node for the communication link, the link data rate and the RF-path loss on the communication link, which is determined by a neighbor node comparison of the RF transmit power to a received signal strength at the neighbor node. The cost metric may also include measure of node energy consumed per data bit for transmissions over a communication link within the computer network. Node energy may be computed so as to account for all power not used by a node in a non-transmitting state.

[0001] This application is a divisional of U.S. patent application Ser.No. 09/221,228, filed Dec. 23, 1998.

STATEMENT OF GOVERNMENT LICENSE RIGHTS

[0002] The United States Government has a paid-up license in portions ofthis invention and the right in limited circumstances to require thepatent owner to license others on reasonable terms as provided for bythe terms of Contract No.: DAAH01-97-C-R124, awarded by the U.S. ArmyMissile Command.

FIELD OF THE INVENTION

[0003] The present invention relates to routing protocols in networksand, more particularly, to routing protocols for ad-hoc networks, inwhich both routers and hosts may be mobile, and in which routers may beconnected to both hosts and networks.

BACKGROUND

[0004] Packet-radio technology has the potential of becoming a majorcomponent of the global information infrastructure, at least in partbecause it requires no wiring and need not require third-party serviceproviders or the configuration of forwarding tables. However, therouting approaches that have been proposed or implemented to date forthe Internet or ad-hoc networks (i.e., those networks which do not havea preconceived topology) do not allow for non-technical users to installand operate such networks (or any multi-hop packet-radio networks) asseamless extensions of the Internet.

[0005] In traditional Internet routing approaches, bridges or routersare used to forward data packets using media access control (MAC)- ornetwork-level addresses, respectively. Performing routing at the linklevel using transparent bridges has the advantage that limitedconfiguration is required for the bridges and hosts used in theinternetwork; furthermore, the frames forwarded by bridges canencapsulate any type of network-level protocol (e.g., Internet protocol(IP) and Internet packet exchange (IPX)). The disadvantage of usingtransparent bridges for network interconnection is that both data andcontrol packets (frames) are sent over a spanning tree to avoid loopingof packets, which means that data packets are sent over paths longerthan the shortest paths and the available bandwidth is underutilized.Furthermore, in an ad-hoc network, maintaining a spanning tree may incurexcessive overhead depending on mobility. On the other hand, performingrouting at the network level facilitates aggregation of routing updates,and permits data packets to be sent over the shortest paths using theavailable links efficiently. The disadvantages of this approach are thatrouters have to be configured with appropriate addressing informationbefore they can start forwarding packets, network-level addresses haveto be carefully allocated, and the router must understand whichnetwork-level protocol is being routed (e.g., IP or IPX).

[0006] All routing protocols proposed and implemented to date for eitherad-hoc networks or the Internet fall into two major categories:table-driven and on-demand routing protocols. In a table-driven routingprotocol, a router maintains a routing-table entry for each destinationin the network and runs a routing-table update algorithm to maintainup-to-date entries. Table-driven routing protocols have been proposedbased on topology broadcast or the dissemination of vectors ofdistances. In an on-demand routing protocol, a router maintainsrouting-table entries for only those destinations with which it needs tocommunicate. A typical on-demand routing protocol requires a router touse a flood search method to determine the shortest paths todestinations which it does not currently have a routing-table entry.

[0007] Each type of protocol has its advantages and disadvantages. Forexample, a table-driven routing protocol supports datagram traffic veryefficiently and can detect network partitions very quickly; however,each router must exchange routing information for all the destinationsin the network or internetwork, which may be taxing on the battery lifeof tetherless wireless routers. By contrast, an on-demand routingprotocol does not require routers to send updates regarding thosedestinations with which they do not communicate; however, routers needto search for an unknown destination before they are able to forwarddata to it. Consequently, on-demand routing approaches are typically notwell suited for datagram traffic. On-demand routing also incurs muchmore control traffic than table-driven routing protocols when thenetwork or internetwork becomes partitioned or routers fail, due to theresulting repeated generation of flood search packets, which onlydiscover that the destinations are unreachable.

[0008] Routing in ad-hoc networks is typically accomplished by treatingthe entire ad-hoc network as an opaque sub-network using a routingprotocol within the sub-network to forward data packets from one end ofthe sub-network to the other. In such methods, the ad-hoc network simplylooks like a link (or set of links) to the IP layer. Although thisapproach is appealing at first glance, it does not avoid any of theaddress assignment, router configuration, and management issuesassociated with Internet routing. Thus, what is needed is a new approachfor routing within ad-hoc networks.

SUMMARY OF THE INVENTION

[0009] In one embodiment, routing table update messages that includeboth network-level addresses and other (e.g., link-level, possiblyMAC-level) addresses of nodes of a computer network are exchanged amongthe nodes of the computer network. The update messages may exchanged inresponse to an indication that a new node has been added to the computernetwork or that one of the nodes has been dropped from the computernetwork (e.g., that communication with the node has been lost). Further,a routing table maintained by a first one of the nodes of the computernetwork may be updated in response to receiving one or more of theupdate messages.

[0010] The routing table is preferably updated by selecting a next nodeto a destination node of the computer network only if every intermediatenode in a path from the next node to the destination node satisfies aset of nodal conditions required by the first node for its path to thedestination node and the next node offers the shortest distance to thedestination node and to every intermediate node along the path from thenext node to the destination node. The shortest distance to thedestination node may be determined according to one or more link-stateand/or node-state metrics regarding communication links and nodes alongthe path to the destination node. Also, the nodal characteristics of thenodes of the computer system may be exchanged between neighbor nodes,prior to updating the routing table. Preferred paths to one or moredestination nodes may be computed according to these nodalcharacteristics, for example using a Dijkstra shortest-path algorithm.

[0011] In some cases, the exchange of routing table update messages mayinvolve exchanging node distance and node predecessor information amongthe nodes of the computer network. Such information may be included inthe update messages and individual entries in each update message may beprocessed in order at a receiving node of the computer network.Transmitting nodes of the computer network preferably order theindividual entries in the update messages according to distances todestination nodes. Further, for each entry of one of the updatemessages, one of the receiving nodes may determine whether an implicitpath to one of the destination nodes defined by the node distance andnode predecessor information is free of loops. In yet further cases, arouting table entry for a destination node that was establishedaccording to path information provided by a first neighbor node, at afirst of the nodes of the computer network may be updated according toinformation included within at least one of the update messages receivedfrom a second neighbor node.

[0012] In a further embodiment, routing tables for a computer networkmay be updated by disseminating routing table update informationregarding nodes of the computer network that are well known throughoutthe network. In such cases, the update information includes bothnetwork-level and link-level addresses for the well-known nodes.Moreover, further updating may be accomplished by transmitting routingtable update information regarding nodes that are not well knownthroughout the computer network in response to search queries regardingsuch nodes. In some cases, the search queries are flooded throughout thecomputer network on a best-effort basis. New search queries may betreated as network-level queries and retransmitted search queriestreated as host-level search queries.

[0013] Upon receipt of one of the search queries, a first node of thecomputer network may search a query cache to determine whether it hasalready processed that search query. In addition, the first node maydetermine whether that search query is a host-level search query or not.

[0014] If the first node determines that the search query is ahost-level query, the first node may respond to the search query if ithas not already done so and if it is able to provide path information toa destination specified in the search query. Alternatively, if the firstnode has not already responded to the search query but does not have thepath information to the destination, the first node may transmit a localrequest for the path information to local hosts associated with thefirst node. In those cases where the first node receives a localresponse to the local request, the first node transmits the pathinformation from the local response in response to the search query.Otherwise, the first node transmits the search query to neighbor nodesof the computer network if there are any. On the other hand, if thefirst node determines that the search query is not a host-level query,the first node either transmits a response to the search query if thefirst node has path information to a destination specified in the searchquery or forwards the search query to neighbor nodes of the computernetwork, if any.

[0015] The routing table update information regarding nodes that are notwell known throughout the computer network may be provided as searchquery response messages by one or more nodes of the computer networkhaving path information relating to the nodes that are the subject ofthe search queries. In such cases, one of the nodes having the pathinformation adds a path entry for itself to the path information beforeproviding an associated search query response message. The path entryincludes a network-level and a link-level address of the node having thepath information and may further include a network-level and alink-level address of a node from which the node having the pathinformation received the search query.

[0016] Preferably, at least one of the nodes of the computer networkmaintains a table of the search queries it has transmitted. Such a tableof search queries may include an indication of whether a particularsearch query is a network-level search query or a host-level searchquery.

[0017] Note, however, that network-level search queries may beretransmitted as host-level search queries within the computer networkif no responses are received to network-level searches.

[0018] In yet another embodiment, a routing table in a computer networkmay be updated by specifying a path from an origin of a search query toa destination in the computer network that is the subject of the searchquery, the path including both network-level and link-level addresses ofthe destination. The path is relayed between nodes of the computernetwork, from a first node that produces the path to the origin of thesearch query. However, any one node of the computer network relays thepath only if it is included in the path between the origin of the searchrequest and the destination. Relaying nodes of the computer network thatreceive the path, may update respective routing tables to include thepath but only retain the path in their routing tables if the path isassociated with a node that is well known throughout the computernetwork. Otherwise, the path is removed from their respective routingtables after a specified period of time.

[0019] Still another embodiment provides routing table having anetwork-level address of a destination node of a computer network and alink-level address of the destination node. The network-level addressand link-level address are preferably included in a single entry of therouting table regarding the destination node. The network-level addressis preferably an Internet protocol (IP) address, while the link-leveladdress is preferably a medium access control (MAC) address.

[0020] The single entry in the routing table may further include pathinformation (e.g., distance and/or predecessor information) regardingthe destination node. Such distance information may be based onlink-state information and/or node-state information of a path withinthe computer network. In some cases, the path is a shortest path betweenthe destination and a node that maintains the routing table. Thepredecessor information refers to a node of the computer network that isthe second-to-last hop from the node that maintains the routing table tothe destination along the path.

[0021] Generally, the routing table is maintained by a router, which mayalso have a distance table that is configured to store routing treeinformation received by the router from neighbor nodes of the computernetwork. The router may further have a message retransmission list thatis configured to include information regarding routing table updatemessages transmitted by the router to the neighbor nodes.

[0022] Still additional embodiments provide various cost metrics for acomputer network. Among these are measures of interference over time toneighbor nodes of a first node of the computer network per data bittransmitted on a communication link used by the first node. Such ametric may be estimated using the RF transmit power used by the firstnode for the communication link, the link data rate and the RF-path losson the communication link, which is determined by a neighbor nodecomparison of the RF transmit power to a received signal strength at theneighbor node.

[0023] Another cost metric may be a measure of node energy consumed perdata bit for transmissions over a communication link within the computernetwork. Here, node energy is computed so as to account for all powernot used by a node in a non-transmitting state.

[0024] A further cost metric may be a measure of the quality of awireless communication link within the computer network. Such a metricmay find use in determining which links of the network to utilize. Forexample, one may examine local routing information maintained by a firstnode of a computer network to determine whether alternate paths exist toa neighbor node of the first node, using a sequence of one or more linksother than a candidate link through the computer network and compute alink quality of the candidate link. Then, if no alternate path exists tothe neighbor node, or the link quality of the candidate link exceeds adefined threshold value, the candidate link may be accepted. If one ormore alternate paths do exist to the neighbor node, then by comparinglink qualities of the links along each of the alternate paths with thelink quality of the candidate link one may decide to accept thecandidate link if the link quality of the candidate link comparesfavorably with the link qualities of the links on the alternate paths.

[0025] Such a favorable comparison may be one wherein the link qualityof the candidate link is equal to or better than a link quality of aworst one of the link qualities of the links on the alternate paths, orone wherein the link quality of the candidate link is equal to or betterthan a path quality function of the links along the alternate paths. Forexample, if the link quality of any link in the computer network isequal to the probability of success for each packet transmitted overthat link. Then the path quality function of the links along thealternate paths comprises the products of the link qualities for each ofthe links on the alternate paths.

[0026] Metrics for individual nodes of a computer network may also beused. For example, metrics, which are an indication of the type of poweravailable to the node, the power state of the node, or an indication ofwhether the node is an anchor for the computer network.

BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The present invention is illustrated by way of example, and notlimitation, in the figures of the accompanying drawings in which likereference numerals refer to similar elements and in which:

[0028]FIG. 1 illustrates an ad-hoc network that includes a number ofsub-networks and an interconnection to the Internet through a routermaintained by an Internet service Provider (ISP);

[0029]FIG. 2A illustrates another example of an ad-hoc network topology,including node IP-level and MAC-level addresses;

[0030]FIG. 2B illustrates a routing tree communicated by one of thenodes of the ad-hoc network illustrated in FIG. 2A in accordance withone embodiment of the present invention;

[0031]FIG. 3 illustrates an example of a routing table that may bemaintained by an Internet Radio (IR) according to one embodiment of thepresent invention;

[0032]FIG. 4 illustrates an example of a distance table that may bemaintained by an IR according to one embodiment of the presentinvention;

[0033]FIG. 5 illustrates an example of a message retransmission listthat may be maintained by an IR according to one embodiment of thepresent invention;

[0034]FIG. 6 illustrates an example of a routing-table update messageaccording to one embodiment of the present invention;

[0035]FIG. 7 illustrates an example of a search query according to oneembodiment of the present invention;

[0036]FIG. 8 illustrates an example of a search query response accordingto one embodiment of the present invention;

[0037]FIG. 9 illustrates a network having a topology useful forunderstanding the routing table update mechanisms found in an embodimentof the present invention; and

[0038]FIG. 10 illustrates an example of a query sent table maintained bya node of an ad-hoc network in accordance with one embodiment of thepresent invention.

DETAILED DESCRIPTION

[0039] Presented below is an Ad-hoc Internet Routing (AIR) protocol thatprovides a unified scheme for ad-hoc internetworking. Because supportingtraffic to and from the Internet is likely to be a key requirement ofad-hoc networks, the hosts and networks attached to the packet radioswith which the ad-hoc network is built (which will be referred to asInternet Radios or IRs) need Internet addresses. These Internetaddresses are needed even if the IRs support routing at the sub-networklevel or link level within the ad-hoc network. Assigning Internetaddresses to IRs also provides benefits from the standpoint of networkmanagement, because it enables the use of standard and emerging networkmanagement products based on the simple network management protocol(SNMP).

[0040] AIR enables ad-hoc internets by supporting routing at the IPlayer rather than below it. Thus, AIR advances the state of the art inrouting in ad-hoc networks in a number of ways. For example, AIR usesboth medium-access control (MAC) addresses and Internet addresses whileproviding shortest paths to known destinations. For some embodiments,the shortest (or preferred) path calculations may be made on the basisof link-cost metrics and/or node-cost metrics. Further, AIR permits anIR to act as the proxy destination node for all the hosts attached tothe IR, or to act as an intermediary between senders and receivers ofAddress Resolution Protocol (ARP) requests. These address-mappingservices allow the hosts attached to the IRs to perceive the ad-hocinternet as a single broadcast LAN. Also, AIR updates routing-tableentries using both source- and destination-based routing-table updatemechanisms.

[0041] AIR is discussed in greater detail below, with reference tocertain illustrated embodiments. However, upon review of thisspecification, those of ordinary skill in the art will recognize thatAIR may find application in a variety of systems. Therefore, in thefollowing description the illustrated embodiments should be regarded asexemplary only and should not be deemed to be limiting in scope.

[0042] Overview of AIR Protocol

[0043] AIR is well suited for an ad-hoc internet that provides aseamless extension of the IP Internet to the ad-hoc wirelessenvironment. In contrast to the IP Internet, mobility of hosts androuters, and changes to link- and/or node-costs are the rule, ratherthan the exception, in an ad-hoc internet. FIG. 1 illustrates aspects ofan exemplary ad-hoc network that will assist in understanding theremaining discussion.

[0044] Ad-hoc network 10 may be considered as a number of sub-networks12 a, 12 b, 12 c, which provide an extension of the Internet 14 througha number of IRs 16 a-16 i. Each IR 16 a-16 i may be a packet radio withan assigned IP address. In general, the IRs 16 a-16 i operate over asingle channel using spread spectrum wireless communication techniquescommon in the art. For example, the IRs 16 a-16 i may operate in one ofthe unregulated UHF frequency bands, thereby obviating the need foroperating licenses. At each IRs 16 a-16 i, AIR may run on top of a UserDatagram Protocol (UDP), similar to the Routing Information Protocol(RIP). As the figure illustrates, an IR is essentially a wireless IProuter; with the exceptions that: AIR substitutes for traditionalinternet routing protocols like RIP or the open shortest path first(OSPF) protocol, the AIR routing protocol interacts through sharedtables with the link-layer protocols in order to reduce control trafficneeded to maintain routing tables, and the AIR channel access protocolsare designed for the broadcast radio links 24 a-24 j of ad-hoc network10.

[0045] Coupling of ad-hoc network 10 to the Internet 14 is achievedthrough a router 18, which may be operated by an Internet ServiceProvider (ISP). As shown, a single ISP may operate a LAN 20 to whichmultiple IRs are connected. In such a scheme, IRs 16 a and 16 b may actas “AirHeads”, providing gateway service to Internet 14 via router 18.Some IRs, e.g., IRs 16 d and 16 e of FIG. 1, may be associated withhosts, 22 a, 22 b and 22 c that can be accessed by any Internet userthrough ad-hoc network 10.

[0046] AIR is based on a routing-table updating approach as introducedin the Wireless Internet Routing Protocol (WIRP) described by J. J.Garcia-Luna-Aceves et al., “Wireless Internet gateways,” Proc. IEEEMILCOM 97, Monterey, Calif., Nov. 2-5, 1997, pp. 1271-76; and S. Murthyand J. J. Garcia-Luna-Aceves, “An Efficient Routing Protocol forWireless Networks,” Proc. IEEE INFOCOM 97, Kobe, Japan, April 1997.However, AIR extends WIRP in a number of ways. First, AIR allows IRs touse both MAC-level (i.e., link level) and Internet (i.e., IP) addressesin the routing tables. Second, AIR uses both table-driven and on-demandmechanisms to update routing-table entries. Third, AIR supports proxyARP services to the hosts attached to IRs. Fourth, AIR uses both linkmetrics and node characteristics to compute paths to destinations.

[0047] Another difference between AIR and WIRP is that AIR uses theservices provided by a dedicated neighbor management protocol, whichmaintains the status of an IR's connectivity with its neighbors. Incontrast, WIRP implements its own mechanisms to ascertain theconnectivity of an IR with its neighbors.

[0048] Each IR communicates a hierarchical routing tree to its neighborsin an incremental fashion. The hierarchical routing tree reported by anIR consists of all the preferred paths by the IR to each network, IR,and host with which the IR needs to communicate or to which it needs toforward traffic according to requests received from neighbor IRs. Anentire remote IP network is simply a node in the routing tree. FIG. 2Ashows a simple network topology and FIG. 2B shows the routing tree thatIR (or node) n3 notifies incrementally to its neighbors.

[0049] The way in which an IR disseminates routing information about agiven destination is determined by the value of a dissemination-typeflag in the routing table. Changes to routing-table entriescorresponding to IP networks or nodes where servers are located aretypically disseminated throughout the ad-hoc internet, while changes torouting-table entries corresponding to individual IRs and hosts aredisseminated on demand. FIG. 2B illustrates this point. Note that therouting tree notified by node n3 does not include node n0, because n0 isnot a node that must be known throughout the ad-hoc internet and node n3does not need to communicate with or forward data through n0. It is alsoimportant to note that the addresses used to identify nodes in thead-hoc internet are both IP addresses and MAC-level addresses.

[0050] IRs exchange their hierarchical routing trees incrementally bycommunicating only the distance and second-to-last hop (predecessor) toeach destination. In the case of destinations within or directlyattached to an IR's own IP network, the second-to-last hop consists ofan IR (i.e., a host-level IP Address). In the case of a remote IPnetwork known to the IR and not directly attached to the IR's own IPnetwork, the predecessor consists of another IP network. Hence, internetrouting in AIR does not require an IR to store more routing-tableentries than an Internet routing protocol like RIPv2 would, for example.An IR communicates updates to its routing tree by means of routing-tableupdates sent as a result of connectivity changes, periodically, or inresponse to on-demand search queries. AIR permits IRs to search forpaths to known IP addresses obtained through a name server, or to searchfor the actual location of an IP host that moves from one IR to anotherand remains quiet. Connectivity changes are communicated to AIR by theneighbor protocol implemented in the IR.

[0051] Routing information is exchanged among neighboring IRs by meansof update messages, search queries, and replies to such queries. Updatemessages are used to update routing-table entries that must be known byall IRs in the ad-hoc internet. Search queries are used to updaterouting-table entries on a demand basis.

[0052] From the standpoint of host-level involvement, it is notefficient to require that all hosts in a large ad-hoc internet receivean ARP request whenever any given host sends such a request. AlthoughIRs permit hosts to operate as if they were attached to a common LAN,IRs have much more routing information than do traditional transparentbridges. In particular, they know about both MAC and IP-level addressesof destinations. Accordingly, as long as IRs know which hosts arecurrently attached to them, they need not ask hosts to answer ARPrequests, because the IRs attached to the destination hosts can answerfor them. In some cases hosts that are already configured may relocateand remain silent after moving from one IR to another. In such cases,there may be no IR that can provide the correct mapping of IP to MACaddress and the ARP request may have to be answered by the hoststhemselves.

[0053] Two classes of search queries may be defined in AIR: IR-levelsearches and host-level searches. In an IR-level search, an IR receivingthe query processes the query without forwarding any request to itsattached hosts, if it has any. In a host-level search, an IR receivingthe query processes the query as in the case of an IR-level search andalso sends an ARP request to its attached hosts. IR-level searches arelikely to suffice most of the time, because IRs know their attachedhosts as soon as the hosts send ARP requests to the associated IRs.Accordingly, IRs may attempt IR-level searches before attemptinghost-level searches.

[0054] AIR can be functionally divided into three main components: theproxy and indirect ARP mechanisms, the routing-table update algorithm,and the reliable exchange of updates. Each of these functionalcomponents is addressed in the following sections.

[0055] II. Information Maintained in AIR

[0056] For the purposes of routing, each IR maintains a routing table, adistance table, and a message retransmission list. As shown in FIG. 3,the entry for a destination j in IR i's routing table includes thedestination's IP address, its MAC address, or both, the distance to thedestination (Dij), the successor (Sij), and the predecessor (Pij) alongthe preferred path (e.g., the shortest path) to the destination. Thepredecessor to a destination is the second-to-last hop along thepreferred path.

[0057] The routing table also maintains two markers used to update therouting-table entries, a path traversal tag and a dissemination-typeflag. The path-traversal tag for a destination j specifies whether theentry corresponds to a simple path (tag=correct), a loop (tag=error) ora destination that has not been marked (tag=null). This tag is used toreduce the number of routing table entries that need to be processedafter each input event impacting the routing table. Also for destinationj, the dissemination-type flag determines how the IR maintains the entryand how it disseminates updates to the entry. If the value of the flagis set (e.g., to one), the destination is well known in the ad-hocinternet. In such cases, the IR recognizes that it must keep an entryfor the destination at all times, and that it must report changes to thedistance or predecessor to the destination. If the value of thedissemination-type flag is not set (i.e., is zero), the IR does notreport changes to the distance or predecessor information for thatdestination in update messages to its neighbors; rather, the IR keepsthe entry for a finite amount of time given by an age field that ismanaged locally.

[0058] The routing table of a given IR contains an entry for a subset ofall the destinations in the ad-hoc internet. The IR maintainsrouting-table entries for only those destinations with which it has tocommunicate or to which it has to relay information.

[0059] As illustrated in FIG. 4, the distance table of an IR maintainsthe routing-tree information reported by each of its neighbor IRs. Eachentry reported by a neighbor IR in an update message or a search queryconsists of a set of addresses for the destination (typically a MACaddress, an IP address, or both), the distance to the destination, andthe predecessor in the path to the destination. More generally, the setof addresses may include a network-level address and another address,for example a link-level address (e.g., addresses defined by the IEEE802 family of standards for computer networks) or a sub-network address,where appropriate.

[0060] An underlying neighbor protocol may be used to update the routingtable indicating changes in connectivity with neighbors. When theneighbor protocol detects a new neighbor or loss of connectivity with aneighbor, it updates an entry for the IR or host in the routing tableand notifies AIR of the need to update the distance table andpredecessor information in the routing table. The neighbor protocol mayalso provide an IR with information about the cost of a link with aneighbor IR in both directions.

[0061] As illustrated in FIG. 5, a Message Retransmission List (MRL) maybe used to specify one or more retransmission entries. For example, agiven MRL entry may specify: the update message that is being sent toneighbor IRs, a retransmission counter that is decremented every timethe IR retransmits the same update message (in one embodiment, eachupdate message may be sent a maximum number of times, for example fourtimes), and an ACK-required flag for each neighbor IR specifying whetheror not the neighbor has acknowledged the update message. An IR uses theMRL to ensure that updates are sent reliably to its neighbors.

[0062] III. Information Exchanged in AIR

[0063] A routing-table update message generally includes the identifierof the sending IR (typically its IP address), a sequence number assignedby the sending IR, and an update list of one or more entries. The updatemessage may be formatted as a packet as shown in FIG. 6. Appropriateheader and/or trailer information may be included for addressing and/orerror correction purposes, etc.

[0064] An update entry specifies whether the entry is an update to therouting table of the sending IR or an acknowledgment (ACK) to an updatemessage. An update entry preferably specifies at least one address for adestination, a predecessor for the destination, and a dissemination-typeflag that indicates the way in which the receiving IR should notify itsown neighbors about changes in its distance or predecessor to thatdestination. An ACK entry should specify the sequence number and thesource of the update message being acknowledged. The dissemination flagof an update entry is usually set, because an IR need only send updatemessages to its neighbor IRs concerning those destinations that must bewidely known in the ad-hoc network.

[0065] As shown in FIG. 7, a search query generally specifies the MACand IP address of the sending IR, a sequence number, and the forwardpath traversed by the query from its originating IR to the IR forwardingthe query. This forward path may be specified using entries that are thesame as the update entries in update messages. The dissemination-typeflag of a forward-path entry may or may not be set, depending on whetherthe intermediate hop corresponds to an IR or network that must be knownby other IRs or not.

[0066] As illustrated in FIG. 8, a response to a search query mayspecify the MAC and IP address of the sending IR, the sequence number ofthe query being answered, and the complete path from the IR thatoriginated the query to the destination. Note that the IR responding toa query has to notify a complete path to a destination only if itincludes intermediate hops that are not known throughout the ad-hocinternet. However, in one embodiment of AIR, complete paths are used inorder to simplify the protocol. Each hop in the path specified in aresponse to a search query is specified in terms of: the address(es) ofthe intermediate hop(s), the predecessor and distance to the hop(s), andthe dissemination-type flag for the hop(s) (which may be set or not).The distance and predecessor information for each hop specified in theresponse may be obtained directly from the responding IR's routingtable.

[0067] Because update messages are used to update routing informationfor well-known destinations, update entries always correspond todestinations that are known throughout the ad-hoc internet. In contrast,the entries of a reply to a search query may correspond to eitherwell-known destinations or destinations that IRs receiving the replyneed not mention to their neighbor IRs, except the neighbor thatrequested the information. In one embodiment of AIR, dissemination-typeflags are included in update entries. Further, an IR may order therouting information it sends in update messages, search queries, orreplies to such queries based on its distance to the destination. IV.Proxy ARP and Indirect ARP Mechanisms

[0068] Returning now to FIG. 1, it should be noted that AIR allowshosts, e.g., 22 a, 22 b and 22 c, in the ad-hoc network 10 to operate asif they were all attached to a common local-area network (LAN). Forexample, hosts 22 a and 22 b attached to IR 16 d through a LAN or aserial (or other) interface 26, view IR 16 d as the destination, unlessthe destination is attached to the same LAN 26 or the hosts 22 a and 22b are configured with the MAC address of destinations (i.e., as if theywere physically attached to LAN 26). IR 16 d is then capable ofdetermining the correct paths to the true destinations (specified interms of IP or MAC addresses) by means of the routing-table updatemechanisms described below.

[0069] For a host to communicate with another host using end-to-endprotocols running on top of the Internet Protocol (IP), the source hostmust first obtain the Internet address (IP address) of the destinationhost. This is accomplished by means of a directory service (e.g., theDomain Name System or DNS), which maps domain names to IP addresses. Ifthe source and destination hosts share a common LAN, the source hostneeds also to find the MAC address of the destination host. The MACaddresses serve as the name of the hosts inside a LAN and permit thenetwork interfaces with which hosts attach to the LAN to provide a hostwith only those packets addressed to it. For example, in Ethernet LANsthe mapping of a destination's IP address to its MAC address issupported by the ARP.

[0070] Because an ad-hoc internet typically has multiple hops, when anattached source host (e.g., host 22 a in FIG. 1) sends an ARP requestfor a destination host (e.g., host 22 c) that is not directly attachedto a common IR, the IR (e.g., 16 d) connected to the source host actslike a destination and answers the ARP request. That is, it provides aproxy ARP service to all the hosts attached to it through a LAN orserial (or other) interface (e.g., LAN 26). The IR (e.g., 16 d) thenfinds the shortest (e.g., as measured by an appropriate metric or set ofmetrics) path to the destination host (e.g., 22 c) in collaboration withother IRs (e.g., IR 16 e in this example) using the routing-tableupdating mechanisms, which are completely transparent to its attachedhosts. Accordingly, an IR serves as the default router for all the hoststhat attach to it through a common LAN or serial interface.

[0071] The mechanisms used by an IR to learn the MAC address of adestination are described within the context of routing-table updating.The IR responds to an ARP request from a host as soon as it obtains thenext hop to the intended destination. The steps taken by an IR to obtaina path to a destination are transparent to the host sending an ARPrequest, because the allowed delays in getting an ARP response aretypically longer than the time it takes to obtain a path to an intendeddestination if it can be reached in an ad-hoc internet.

[0072] An IR also provides what may be defined as indirect ARP serviceto its attached hosts. This service consists of forwarding an ARPrequest from an attached host towards the MAC address specified by thehost. To illustrate, consider that, in some cases, hosts attached to anIR through a LAN may be configured with a default router other than theIR(s) directly attached to the LAN. This may occur after a host isrelocated or IRs are used to bridge two or more segments of a LAN. Topermit a configured host to continue operating when its default routeris not the IR(s) attached to the host's LAN segment, an IR is able tolisten to frames (packets) sent to MAC addresses other than its own. Ifthe IR has a routing-table entry for the MAC address, it can forward thepacket accordingly. If the IR does not have a routing table entry forthe MAC address, and the node with such an address has not been heard inthe attached LAN, the IR may send a search query in order to find a pathto the intended MAC address.

[0073] V. Routing-Table Updating

[0074] Routing-table updates are important because they serve as themeans by which routers (which generally use “path finding” algorithms todetermine preferred paths—typically shortest paths) ensure that they areusing truly preferred paths to destinations. To illustrate, consider thenetwork topology shown in FIG. 9. In traditional approaches, a router isets its next node t6 destination j to equal neighbor k only if thedistances to j, and to every node in the path from k to j, through nodek constitute the smallest distances for such destination j and for suchintermediate nodes (e.g., p) in the path from k to j known at i amongall the neighbors of node i. For AIR, however, a router i selects itsnext node to a destination j to equal neighbor k only if the followingconditions are satisfied:

[0075] Every intermediate node in the path from k to j, reportedincrementally by k to i and stored at i, satisfy the nodal conditionrequired by i for its path to j, and

[0076] For all of router i's neighbors, neighbor k offers the smallestdistance to j and to every intermediate node along the path from k to j,which is reported incrementally by k to i and stored at i.

[0077] Furthermore, AIR extends the methodologies used in prior schemesfor link-state routing. In such schemes, a router i may communicate toits neighbors the characteristics of the links (e.g., 30 a and 30 b) toeach of its neighbors. A router that receives a link-state update from aneighbor may then propagate the update to its own neighbors (e.g., ifthe link-state update is more recent than the information maintained atthe node) in one of two ways. The router may forward the update to allits neighbors other than the one sending the update, or the router mayforward the update to all its neighbors if the link in the update isused by router i to reach at least one destination. A router thencomputes its preferred paths to destinations based on the updatedinformation by running a shortest-path algorithm.

[0078] In AIR, however, in addition to the link-state updates, a routeri communicates to its neighbors its own nodal characteristics (i.e., thenode-state metrics of node i). A router that receives a node-stateupdate from a neighbor propagates the update to its neighbors if thenode-state update is more recent than the information maintained at thenode. Routers then compute preferred paths to destinations running ashortest-path algorithm (e.g., Dijsktra's or Bellman-Ford's algorithm)modified to eliminate from the computation those nodes that do notsatisfy router i's required value of nodal characteristics. Theshortest-path algorithm may be implemented in a distributed manner overa hierarchical graph representing the connectivity of IRs (i.e., thenodes of the ad-hoc internet) and the IP networks they connect. Examplesof nodal characteristics (or metrics) that may be communicated amongnodes (and, hence used in shortest path computations) are presentedbelow.

[0079] To expand on the above discussion then, an IR updates its routingtable based on AIR control messages received from other IRs or messagessent by the neighbor protocol. The control messages that can cause an IRto modify its routing table are update messages or search queries fromother IRs. As previously stated, the routing information contained inboth update entries and query entries generally include the address (MACaddress, IP address, or both), and the distance and predecessor to thedestination along a preferred path. Because every IR reports to itsneighbors the second-to-last hop in the shortest path to thedestination, the complete path to any destination (called the implicitpath to the destination) is known by the IR's neighbors, whether thedestination is well-known in the ad-hoc internet or not.

[0080] When an IR receives an update message from a neighbor, itprocesses each update entry and ACK entry in order. Similarly, when anIR receives a reply to a search query, it processes each hop of thereported path one at a time and in the order in which the senderspecifies them. Because IRs send routing information ordered accordingto their distances to destinations, it follows that an IR can safelyexecute the following path-traversal mechanism to determine if using aneighbor IR to reach a destination would result in a loop.

[0081] VI. Processing Update Messages

[0082] When an IR processes an update message from one of its neighbors,it processes each update entry reported by its neighbor IR in the orderin which it was sent in its neighbor's update message. For each updateentry in the message, the IR checks whether the implicit path reportedby a neighbor IR to a given destination is free of loops, and checks theconsistency of predecessor information reported by all its neighbors.

[0083] When an IR processes an update or reply entry reported byneighbor k regarding destination j, the IR updates the path informationfrom neighbor k that it maintains in its distance table with the newpath information reported by the neighbor. In addition, the IRdetermines if the path reported by any other neighbor n to the samedestination includes neighbor k. If that is the case, then the IRsubstitutes the old path information reported by neighbor n regardingthe subpath from k to destination j with the path information reportedby neighbor k regarding its path to destination j.

[0084] As discussed above, to ensure that the implicit paths stored inan IR's routing table are loop free, the IR chooses a neighbor n as itssuccessor (next hop) towards a destination if, and only if, (1) thedistance to the destination through that neighbor is the smallestattainable distance to the destination through any neighbor, and (2) thedistance to each intermediate hop in the path from the IR to thedestination through neighbor n is the smallest attainable distance tothat destination through any neighbor.

[0085] To determine the second condition above, the IR traverses theimplicit path reported by its neighbor through the predecessorinformation. If a given intermediate hop along the path to a destinationsatisfies the second condition for loop freedom, the IR then checks ifthe same condition is true for the predecessor specified for thatdestination by its neighbor n. Hence, the IR carries out a pathtraversal from the destination back to itself to ensure that itsneighbor n provides the shortest path to the destination and everyintermediate hop in the path to the destination. The path-traversal tagis used to limit the processing required for an IR to accomplish thispath traversal. More specifically, the tag allows the IR to stop thepath traversal as soon as it reaches an intermediate hop that has a tagvalue equal to correct, which indicates that the path from itself tothat hop through the same neighbor has been checked successfully before;or a value equal to error, which indicates that a loop has already beendiscovered along the proposed path to the destination.

[0086] VII. Processing Search Queries

[0087] Search queries are flooded throughout the ad-hoc internet on abest-effort basis in order for an IR to find a destination that is notknown by all IRs of the ad-hoc internet. Because IRs need not keep arouting-table entry for every possible source of a search query, IRscannot decide when to forward a query based on their shortest paths tothe origins of the queries. Accordingly, IRs relaying queries shouldmaintain a cache of the search queries that they have forwardedrecently. The minimum information a relay IR requires to discard copiesof the same query arriving from multiple neighbors then becomes theaddress of the origin of the query and the sequence number assigned bythe origin to the query.

[0088] When an IR receives a search query, it first determines if thequery is IR-level or host-level, and whether it has already processedthe query by consulting its query cache. In the case of an IR-levelquery that is new, the IR either forwards the query if it does not knowthe route to the MAC or IP address specified in the query, or replies tothe query if it has a current path to the destination.

[0089] In the case of a host-level query that is new, the IR replies tothe query if it can provide a path and an address mapping for thedestination. If the IR does not have the information, it first sends anARP request locally (e.g., across a local LAN such as LAN 26 in FIG. 1)and replies to the query if it obtains a positive response from anattached host; otherwise, the IR forwards the query to other IRs, if ithas any other neighbors.

[0090] When an IR forwards a search query, it adds a path entry foritself to the forward path information contained in the query. This pathentry includes: the IP or MAC address of the IR; its predecessor, whichconsists of the IP or MAC address of the IR from which the query wasreceived; the distance from the origin of the query to the IR; and thedissemination-type flag for the IR forwarding the query. The IR computesthe distance from the origin of the query to itself by adding the costof the incident link from its neighbor to the distance reported in theforward path of the query for the neighbor that forwarded the query.

[0091] When an IR knows a path to the destination requested in a searchquery, it sends a reply to it specifying the complete path from theorigin of the query to the destination. This path is simply theconcatenation of the forward path specified in the query being answeredand the path from the IR answering the query to the intendeddestination.

[0092] To permit search queries to be IR-level or host-level in a waythat is completely transparent to the hosts of an ad-hoc internet, oneembodiment of the AIR protocol treats new ARP requests as IR-levelqueries and retransmitted ARP requests as host-level queries, and uses acounter to limit the number of host-level queries sent for the same IPaddress during a time interval of a few seconds. In addition toconsuming bandwidth, sending too many host-level requests would impactthe hosts of an ad-hoc internet negatively after network partitionsand/or IR or host failures.

[0093] When a host sends a new ARP request to its attached IR, the IRoriginates an IR-level query and keeps a copy of the query in aquery-sent table for a query-timeout interval. As shown in FIG. 10, anentry in the query-sent table includes the IP address of the intendeddestination, a query-type flag stating whether the entry corresponds toan IR- or host-level query, and a counter. The query-timeout interval islong enough for replies to the query to come back to the originating IRif there are other IRs with a path and address mapping to the requesteddestination, but is smaller than the ARP request timeout at therequesting host.

[0094] If the query-timeout expires for an entry in the query-senttable, the IR increments the counter of the entry in its query-senttable, retransmits the IR-level query, and restarts its query-timeouttimer. If no reply is received to the retransmitted JR-level query, theIR changes the value of the query-type flag (e.g., to one) to reflectthe fact that the next retransmission of the query must be a host-levelquery. The query-timeout is set to equal an ARP request timeout to allowthe attached host to retransmit its ARP request. The IR does notretransmit a search query for the same address unless it receives an ARPrequest from its attached host. If the IR receives an ARP request for anIP address whose entry in the query-sent table has a query-type flag setto one, the IR sends a host-level query, increments the counter for theentry, and starts a query-timeout timer with a value long enough for theremote host to reply to the query.

[0095] An entry remains in the query-sent table of an IR for a longtimeout period that should be larger than the ARP request timeout at theattached hosts, so that the attached host can retransmit an ARP requestif necessary. In one embodiment of AIR, a host-level query isretransmitted only twice, after which an IR simply drops ARP requestsfrom an attached host. This limits the traffic due to flooding of searchqueries over the ad-hoc internet due to ARP requests and also limits thenumber of remote ARP requests reaching the hosts.

[0096] VIII. Processing Replies to Search Queries

[0097] Replies specify complete paths from origins of queries todestinations, because relay IRs do not maintain an accurate account ofthe queries that they have forwarded; the cache maintained at each IR isonly meant to reduce the possibility of an IR forwarding the same querymultiple times. Accordingly, an IR must decide how to process a reply itreceives from a neighbor based entirely on the information contained inthe reply and not the contents of the cache it keeps for queries. Morespecifically, an IR receiving a reply for a query forwards the replytowards the origin of the query if it is listed in the forward path fromthe origin to the destination specified in the reply.

[0098] In addition to forwarding replies to the proper IRs whenapplicable, IRs also use replies to update their routing tables. An IRreceiving a reply treats each path entry with the dissemination-typeflag set in the path specified in the reply as an unreliable updateentry. More precisely, if a path entry in a reply refers to a well-knowndestination, the IR updates its distance and routing tables as if theentry were an update entry, prepares its own routing-table update ifneeded, but does not send an acknowledgment. In addition, an IR treatseach path entry with the dissemination-type flag reset as a temporalrouting-table entry. The IR adds the routing information to its routingtable, and keeps the information for a period of time.

[0099] As the replies from IRs travel back to the origin of the query,the originating IR starts obtaining one or more paths to the intendeddestination. In one embodiment of AIR, the IR originating a search querydoes not keep any state regarding the search queries that are stillpending replies. The sequence number assigned to a search query is usedonly to limit the number of replicas of the same query that relay IRsforward. This design assumes that the hosts attached to the IRs will bethe ones requesting the transmission of more queries if they do notobtain any reply from their attached IRs after a timeout. In practice,the timeouts used in hosts are much longer than the time needed forqueries and their replies to traverse an ad-hoc internet.

[0100] An IR originating a search query may receive as many replies asthere are IRs in the ad-hoc internet that know about the destination andare reached by the query through paths of IRs that do not know about thedestination. In one embodiment of AIR, IRs maintain routing-tableentries for either well-known destinations that every IR must know, oron-demand destinations that IRs know only temporarily through thereplies to queries for those destinations. Therefore, it is anticipatedthat the most replies an originating IR will receive equals the numberof neighbor IRs that a destination IR has, if the destination is an IRor a network, or as many replies as IRs are attached to a host, if thedestination is a specific host. In most cases, on-demand routing willserve host-specific routes. When an IR that originated a search queryreceives the first reply to the query, it should erase the entry for thequery in its query sent table.

[0101] IRs maintain on-demand routing information for a finite period oftime, and add routing-table entries to their routing tables withinformation they receive in replies to search queries, without notifyingtheir neighbors of such changes to their routing tables. An IR keeps arouting-table entry with a zero value of the dissemination-type flag fora finite time period equal to a maximum entry age, which in oneembodiment may be set to approximately 3 minutes or another appropriatetime. The IR may reset the age of the entry (e.g., by updating anassociated age field, which may be part of each routing table entry asshown in FIG. 3) each time it forwards a packet for the destination orreceives a new reply with information about the destination.

[0102] IX. Reliable and Unreliable Distribution of Routing Information

[0103] The reliable transmission of update messages is implemented bymulticasting update messages, and then acknowledging these with messagescarrying both updates and acknowledgments to one or more other updatemessages.

[0104] After receiving an update message free of errors, a node isrequired to acknowledge it. An update message may be retransmitted ifacknowledgments are missing after a finite timeout equal to the updateinterval. An IR keeps track of which neighbor IRs have not acknowledgedan update message by means of its MRL. Each retransmission of an updatemessage may specify the subset of neighbors that need to acknowledge themessage.

[0105] In some cases, the information contained in an update message maybe obviated by a subsequent update message. In one embodiment of AIR,old update messages are therefore discarded, and all the up-to-date pathinformation contained in the old update messages are included in the newupdate message, together with the new information the new update messagemust convey to all neighbor IRs. In other schemes, the new updatemessage may include information regarding which portions of old updatemessage to discard, etc. An IR may receive an acknowledgment to anupdate message that has been replaced by a more recent update message;in such a case, the IR simply ignores the information in theacknowledgment.

[0106] In contrast to the way in which update messages are exchanged, inone embodiment of AIR search queries and their replies are sentunreliably among IRs. The IRs originating search queries retransmit suchqueries only once, and it is up to the hosts to persist in findingdestinations for which there are no routing table entries at each IR. Asnoted above, however, AIR preferably limits the number of search queriesallowed over the ad-hoc internet for a given remote destination.

[0107] X. Simple Network Configuration Through AIR

[0108] With traditional Internet routing protocols, a router has to beconfigured with the IP addresses and masks of the attached LANs, as wellas its own address and mask. Further, hosts attached to routers througha serial link or a LAN have to be configured with their IP address andmask and the IP addresses of their default routers. This amount ofconfiguration information is required in existing Internet routingsolutions because Internet routing protocols require IP addresses toaccomplish routing. Therefore, Internet routers cannot start forwardingdata to destinations until they are assigned their proper IP addressesand they can only send data towards IP destinations; which means thathosts must be properly configured with IP addresses before routers canstart forwarding data to them.

[0109] AIR simplifies the configuration of hosts and IRs in the ad-hocinternet because it permits IRs to use both MAC and IP addresses toestablish paths to destinations. AIR thus enables the implementation ofa simple Dynamic IR Configuration Protocol (DICP) and permits IRs tostart forwarding data for hosts immediately after they are turned on.

[0110] As mentioned above, in the ad-hoc internet each IR registers withan AirHead, i.e., an IR that interconnects the ad-hoc internet to therest of the Internet, such as IR 16 a in FIG. 1. An AirHead isconfigured with an IP address, LAN sub-networks for attached LANs, and adefault router address for the wired segment to which it attaches tointerconnect to the rest of the Internet. The AirHead then receives anIP sub-network for the ad-hoc internet it serves.

[0111] The AirHead (e.g., IR 16 a) may use a standard Internet routingprotocol (e.g., RIP or OSPF) over the wired LAN (e.g., LAN 20)connecting to its default router (e.g., router 18) to advertise itssub-network (e.g., 12 a and/or 12 b) to the default router. The AirHeadis the only IR that needs to be configured in this traditional approach,because it is the only IR that must use standard Internet routingmechanisms to interconnect to the rest of the Internet.

[0112] Other IRs (e.g., 16 c) may obtain an IP address and domain namefrom their associated AirHead (e.g., 16 a), and may serve DHCP (DynamicHost Configuration Protocol) packets from attached hosts (e.g., 22 aand/or 22 b). The DICP provides mutual authentication between new IRsand AirHeads, which can be accomplished by a packet-limited dialoguebetween the IR and AirHead to exchange certificates and public keys, andauthenticate identities. To save address space or permit installationbefore a global IP network assignment is obtained, AirHeads can use aprivate IP address space to assign IP addresses to IRs and hosts. This,of course, makes the hosts and IRs in the ad-hoc internet invisible tothe rest of the Internet; accordingly, the AirHead must provide thetranslation of private IP addresses to the IP address space allocated tothe ad-hoc internet it serves. Importantly, however, the operation ofAIR does not change with the type of IP addresses (public or private)used in an ad-hoc internet. With the services provided by AirHeads andthe DICP, and given that AIR uses both MAC and IP addresses for routing,IRs can start operating after they are turned on. Immediately afterstartup, the IRs can start sending search queries in response to ARPrequests.

[0113] XI. AIR Routing Metrics

[0114] As indicated above, most network routing protocols operate on“metrics” to determine the best path or paths for data traffic to takebetween source and destination nodes. These metrics are most often“link-state” metrics, which give an indication of the desirability (orinversely, the “cost”) of routing traffic over a particular link. Thesimplest link metric is to give each link a cost of “1”, which willcause the routing algorithm to choose paths that take the shortestnumber of links (or “hops”). Another common link metric is the delayacross the link, averaged over some recent history and typicallyincluding both queuing and transmission delay. This will result in therouting algorithm choosing paths of minimum delay. Less common is theuse of “node-state” metrics, which gives an indication of the cost toroute packets through a particular node. To effectively route traffic inthe self-configuring, multi-hop wireless network environment of anad-hoc network, the AIR protocol combines traditional link-state metricswith new types of both link- and node-state metrics. Of course, theserouting metrics may find use in other types of networks as well.

[0115] The link-state metrics used by AIR include LinkNetImpact,LinkEnergy and LinkQuality, each of which is described in detail below.

[0116] LinkNetImpact is a metric that provides the cost in interferenceover time to an IR's neighbors per data bit and may be measured in,

(normalized-number-of-nonintended-receiving-nodes)*(secs per bit).

[0117] The normalized number of nonintended nodes gives an indication ofthe number of other nodes in the network, other than the intendedreceiver-node(s) for this link, which would be interfered with by atransmission over this link. For example, in the ad-hoc network 10 shownin FIG. 1, when IR 16 e transmits over a path including link 24 c toreach Internet 14 through IRs 16 d, 16 c and 16 a, that transmission mayhave the unintended effect of interfering with receptions by IR 16 f(and potentially other transmissions and receptions by IRs in thesub-network 12 b).

[0118] Because some nodes may be closer to the transmitter than others,this “normalized” number of neighbors may be computed in a number ofways. For example, (1) by including only those nonintended nodes thatwould receive the transmission at an RF power above a certain thresholdpower level; (2) by summing the interference levels of all nonintendednodes with the interference level at each node equal to the received RFpower level of transmissions over this link by each of these nodes; or(3) a combination of methods (1) and (2).

[0119] To estimate the LinkNetImpact for use of a particular link, nodesmay tag each (or selected) transmissions with the RF transmit-power usedfor that transmission. Any individual node may then measure the receivedsignal strength of tagged transmissions made by its nearby nodes, andcompute the difference between the transmit power (tagged in the packet)and the received signal strength. This difference will estimate(depending on measurement accuracy) the RF path-loss from thetransmitting node. Periodically then (depending on rate of node mobilityor other environmental dynamics), the node may relay the computed RFpath-loss from each of its nearby nodes back to its neighbors. Given thepath-loss to each of its nearby nodes, and given the transmitted powerand link-date-rate (bits per sec) used for a link to a particularneighbor node, the transmitting node can compute the LinkNetImpact foruse of this link.

[0120] Note that transmit power and link-date-rate, used for a node'sdifferent links, may vary from link to link. These will, in general, beset by link management protocols according to the data-rate and transmitpower that give reasonably reliable use of that link. In fact, the linkmanager may provide the routing algorithm (e.g., AIR) with multiplechoices of links to the same neighbor that tradeoff lower transmit power(with lower LinkNetImpact) for LinkQuality for instance.

[0121] LinkNetImpact differs from prior schemes (e.g., Jim Stevens,Rockwell; Michael Pursley, Univ. of Illinois) where network“interference” was used as a link metric for routing algorithms, in thata measure of the link utilization (e.g., in secs per bit) was notincluded in such schemes.

[0122] LinkEnergy is a metric that provides the node energy consumed perdata bit for transmissions over a selected link and its use recognizesthat for mobile, portable, or unattended wireless nodes that may besolar- or battery-powered, the power used for transmissions over eachlink can be a significant consideration. The units for this metric are

Energy (in Joules or Watts*secs)/bit.

[0123] This metric may include all additional power not normallyconsumed for the node in its quiescent state (when not activelytransmitting). This will include the power to transmit over the selectedlink, adjusting for the RF transmit power setting used for the link, andmay or may not include the power required to put the node in an activestate (if necessary). Given such a link metric, the routing algorithmcan choose paths that minimize the total energy per bit communicatedthrough the network, or may use this metric in combination with othersto achieve a combined routing optimization.

[0124] In the past (e.g., Theresa Meng, Stanford), algorithms forminimum energy routing have been introduced but such schemes did notconsider the speed of the links (which may be adaptive or selectable).

[0125] LinkQuality is a metric that provides a combined indication ofthe desirability of a link in terms of other basic metrics such asLinkReliability, LinkMaxTransmissionUnit (LinkMTU) size, LinkEnergy, andLinkRcvSignalStrength. Although many of these basic metrics may be usedelsewhere as sole determining metric criteria, the combination and theway that the metric is used in AIR is unique. Such a metric may bepassed as part of a routing table update message (e.g., as part of thedistance information described above). Thus, the metric may be used forrouting decisions. The metric may also be used in determining whether toadd a node as a neighbor at all, e.g., depending upon whether thecorresponding link exhibits a better LinkQuality than an existing pathto the target node.

[0126] In the self-configuring, multi-hop wireless environments commonto ad-hoc networks, links to neighbors must be automatically selected bythe nodes. This is in stark contrast to typical routing algorithms wherethe links to neighbor nodes are fixed, or in cellular wireless networksand conventional wireless LANs where selection of links is drasticallysimplified by the limitation that each mobile system is limited to oneor more links with pre-determined “base-station” nodes.

[0127] There are a number of reasons why it may desirable to limit thelist of actively used links to neighbor nodes. Each active link used bya node consumes memory resources within that node for such purposes aspacket queues and maintaining link statistics. Each active link used bya node often requires additional fields in control packets in the MAC,Link, and/or Routing protocols, translating to additional networkoverhead traffic. In addition, by limiting a node's active links to onlythe closest nearby nodes, overall network efficiency is often increaseddue to the fewer number of nodes interfered with by transmissions (seeLinkNetImpact metric above).

[0128] In AIR, a LinkQuality metric may be computed for each link beingused by a node, based on some combination of traditional metrics (seeabove for some examples; in other cases, combinations of LinkNetImpactand/or LinkEnergy together and/or with the reliability of the link maybe used as well). This metric may then communicated throughout thenetwork as part of AIR's update packets. An important aspect of the useof this metric is making the decisions on which links to keep.Specifically, in making a decision on whether or not to add or delete aparticular candidate link to a neighbor from it's actively used neighborlinks, a node will:

[0129] examine the node's local routing information to determine whetheralternate paths exist to the neighbor, using a sequence of one or moreother links through the network,

[0130] compute the LinkQuality of the candidate link (using probing orother methods to compute the basic metrics required for the LinkQualitymetric), and

[0131] if no alternate path exists to this neighbor node, accept thecandidate link into this node's list of active links.

[0132] If one or more alternate path(s) do exist to the neighbor node,then compare the LinkQualities of the links along each of the alternatepath(s) with the LinkQuality of the candidate link. If the LinkQualityof the candidate link compares favorably with the links on the alternatepath(s), then accept the candidate link.

[0133] In alternative situations, after examining the local routinginformation and performing any comparisons, if the LinkQuality isdetermined to be above a defined threshold value, then the candidatelink may be accepted.

[0134] Depending on the metrics used to compute the LinkQuality,favorable comparison may mean that the candidate link's LinkQuality isequal to or better than the link with the worst LinkQuality along thealternate path. Alternatively, favorable results may mean that thecandidate link's LinkQuality is equal to or better than some otherPathQuality function of the links along the alternate path. For example,if LinkQuality was simply equal to the probability of success for eachpacket transmitted over the link, then the following PathQualityfunction may be appropriate to use for comparison purposes:

PathQuality=

[LinkQuality(i)],

[0135] where LinkQuality(i) is the LinkQuality over the i^(th) linkalong the alternate path. Thus, the function computes the probabilitythat a packet with one transmission attempt over each link on thealternate path will successfully reach the destination (neighbor node).

[0136] If the number of active neighbor links for each node is limited,then steps 3, 4, and 5 above, can be modified to add a new candidatelink and reject an existing link (if necessary to meet the limitation onthe number active links to neighbors). This may be achieved by comparingthe LinkQuality and alternate path(s) of the new link with theLinkQualities, and alternate paths(s) of the existing links. Forexample, each existing link's LinkQuality can be increased (or weighted)by some value (to favor existing links), and then these can be comparedwith the LinkQuality of the candidate link. The link with the worstLinkQuality value (as weighted, if appropriate) may be deleted (orsimply not accepted in the case of the candidate link). Excludingexisting links that have no alternate path, or only poor alternate paths(e.g., as measured according to the PathQuality function discussedabove) can further extend this method.

[0137] In prior schemes (e.g., Beyer, Shacham; BBN), algorithms forselecting neighbor links were presented which limit the number of activelinks for each node. However, these schemes did not make use oflink-state information available from a link-state routing protocol suchas AIR.

[0138] Node-state metrics that may be used by AIR (e.g., as part ofrouting table update messages) include NodePowerType, NodePowerState andNodeAnchorFlag. These measures are discussed in turn.

[0139] NodePowerType is a metric that indicates the type of poweravailable to a node. For example, values may include Unlimited-Power,Battery-Power (with the power-capacity of the battery as an optionalargument), and/or Solar-Power. This metric can be included in the updatepackets of the routing protocol and used by the routing algorithm tosteer packets towards power-capable nodes when allowed by network ortraffic stream performance goals.

[0140] NodePowerState indicates the current state (e.g., “up”,“standby”, “down”) and/or power schedule of a node (i.e., thepower-conservation state of a node). For example, values may includePowered-Up, Powered-Standby, and Powered-Down. This metric may beincluded in the update packets of the routing protocol and used by therouting algorithm to steer packets towards nodes that are in more activestates. This allows packets to follow paths of lower delays (becausenodes that are in relatively inactive states are typically sensing thechannel less often, and thus, forwarding through these nodes will takelonger). Further, the scheme allows nodes that are powered-down toremain in that state rather than waking them up to forward packets.

[0141] NodeAnchorFlag is a metric that may be used to assist the userwith network installation and/or maintenance. In a self-configuring,multi-hop network, a node's connectivity with the rest of the networkcannot be determined simply by deciding whether it has links with one ormore nodes (as is the case for cellular or wireless LAN networks, whereeach node is required to have a direct link with a “base-station” node).Therefore, AIR includes this metric, which indicates whether or not anode has been selected by the user to serve as an “anchor” for thenetwork. By passing the state of this metric to the other nodes in thenetwork, each node is able to provide an indication to the user as towhether or not it has a path (possibly over multiple hops) to one ormore network anchors. For instance, this state may be displayed on anLED or other display, indicating whether or not a node is currently“anchored,” thus facilitating network installation.

[0142] Thus, if a single anchor node is selected by the user, then aslong as each other node has a path (over one or more hops) to the anchornode (i.e., each network node is anchored), the user can be sure thateach node also has connectivity with every other node in the network.Also, by designating the node(s) with connectivity to the Internet asthe network anchor(s), then all anchored nodes will also haveconnectivity to the Internet. An anchor then may be thought of a nodethat has or provides connectivity to a server or a service for thecomputer network or a node that monitors connectivity, e.g., to theInternet or some other resource, for the computer network.

[0143] Thus a unified routing scheme for ad-hoc internetworking has beendescribed. Although the foregoing description and accompanying figuresdiscuss and illustrate specific embodiments, it should be appreciatedthat the present invention is to be measured only in terms of the claimsthat follow.

What is claimed is:
 1. A method for determining a cost metric forrouting between a plurality of nodes of a computer network, the methodcomprising: determining a cost metric comprising interference over timeper data bit to each of at least one neighbor node of a first node ofthe plurality of nodes, for a communication link used by the first node.2. The method of claim 1, wherein the interference over time per databit is determined as a normalized number of non-intended receiving nodesmultiplied by seconds per bit.
 3. The method of claim 2, wherein thenormalized number of non-intended receiving nodes is determined bydetermining a number of nodes that would receive a transmission at an RFpower greater than a threshold power level.
 4. The method of claim 2,wherein the normalized number of non-intended receiving nodes isdetermined by summing the received RF power level of transmissions onthe communications link at each of the at least one neighbor node. 5.The method of claim 1, wherein the step of determining a cost metriccomprises: transmitting at an RF transmit power level from said firstnode to each of the at least one neighbor node on the communicationlink; determining the RF path loss by comparing the RF transmit powerlevel to a received signal strength level at each of the at least oneneighbor node; and determining a cost metric for the communication linkusing the RF path loss at each of the at least one neighbor node and adata rate of the communication link.
 6. A method for determining a costmetric for routing between a plurality of nodes of a computer network,the method comprising: determining a cost metric comprising node energyconsumed per data bit for transmissions over a communication link usedby a first node of the plurality of nodes.
 7. The method of claim 6,wherein the step of determining comprises determining a cost metriccomprising a node energy including all additional power not consumed bythe first node in its quiescent state.
 8. The method of claim 6, whereinthe step of determining comprises determining a cost metric comprising anode energy including power required to put the first node in an activestate.
 9. A method for determining a cost metric for routing between aplurality of nodes of a computer network, the method comprising:determining a cost metric comprising a type of power consumed fortransmission by a first node of the plurality of nodes over acommunications link used by the first node.
 10. The method of claim 9,wherein the type of power consumed includes battery power.
 11. Themethod of claim 9, wherein the type of power consumed includes solarpower.
 12. A node capable of operation in a computer network comprisinga plurality of other nodes, wherein the node determines a cost metricfor routing, the cost metric comprising interference over time per datapit to at least one of the plurality of other nodes for a communicationslink used by the node.
 13. The node of claim 12, wherein theinterference over time per data bit is determined as a normalized numberof non-9ntended receiving nodes of the plurality of other nodesmultiplied by seconds per bit.
 14. The node of claim 13, wherein thenormalized number of non-intended receiving nodes is determined bydetermining a number of nodes that would receive a transmission at an RFpower greater than a threshold power level.
 15. The node of claim 13,wherein the normalized number of non-intended receiving nodes isdetermined by summing the received RF power level of transmissions onthe communications link at each of the at least on of the plurality ofother nodes.
 16. The node of claim 12, wherein the node determines thecost metric by transmitting at an RF power level from the node to eachof the plurality of other nodes on the communication link, determiningthe RF path loss by comparing the strength level at leach of theplurality of other nodes, and determining the cost metric for thecommunication link using the RF path loss at each of the plurality ofother nodes and a data rate of the communication link.
 17. A nodecapable of operation in a network comprising a plurality of other nodes,wherein the node determines a cost metric for routing, the cost metriccomprising node energy consumed per data bit for transmissions over acommunications link used by the node.
 18. The node of claim 17, whereinthe cost metric comprises a node energy including all additional powernot consumed by the node in its quiescent state.
 19. The node of claim17, wherein the cost metric comprises a node energy including powerrequired to put the node in an active state.
 20. An apparatus fordetermining a cost metric for routing in a network comprising aplurality of nodes, wherein the cost metric comprises a type of powerconsumed for transmission by a selected node of the plurality of nodes.21. The apparatus of claim 20, wherein the type of power consumedincludes battery power.
 22. The apparatus of claim 20, wherein the typeof power consumed includes solar power.
 23. The apparatus of claim 20,wherein the type of power consumed includes unrestricted power.